1. Field of the Invention
This invention relates to a management system for log data for use in recovery from crashes in a database.
2. Description of the Related Art
In a database system, the following recovery process is applied to prevent data loss when a system goes down. Backup files are maintained to store the most recent version of the data, and used commands are chronologically recorded as a log file. If the system goes down, it is brought back to its status at the time when a failure stopped the operation. In this event, the recovery process reruns the commands stored in the log file to the backup file. The present invention is directed to establish a management system for the log file used in this way.
To facilitate understanding of the log file, updating of the database is first described. In a database system (hereinafter, also referred to as DB system), the management system performs transactions that update the database (hereinafter, also referred to as DB). The transaction is a collection of operations for performing a complete data operation. The transaction has features of completeness and continuity. The completeness means "a status of the transaction is either successful or failure." The continuity means "a processing of a successful transaction will be ensured permanently."
In the DB system, a history of all the updating operations made to the database (hereinafter, also referred to as a log data DB system) are recorded in a historical log file (HLF) to realize the transactions having the above mentioned features. The transaction is ended at the time when the log data are ensured in the historical log file (HLF), i.e., when the log data are recorded positively in the historical log file (HLF).
FIG. 10 is a system structural diagram for use in illustrating an update processing made to the DB. The database system comprises a plurality of terminals, allowing common use of the data stored in the database accessed by two or more persons. In FIG. 10, a terminal A (200a) and a terminal B (200b) are shown as the terminals. The database (hereinafter, represented by two databases DB-1 (201a) and DB-2 (201b)) is typically stored in an external storage (a first external storage (202)). The external storage (202) is connected to a central processing unit (203). Application programs A and B for use in accessing to the databases are operated on a main memory (204) of the central processing unit (203). The central processing unit (203) is also connected to a second external storage (205) that is used for recording the historical log file (206). The historical log file (HLF)(206) is written in this second external storage (205) by a HLF writing processing unit (204a) on the main memory (204).
DB update processing procedures are described in conjunction with FIG. 10.
(1) When the application program A is initiated, the application program A issues a READ macro instruction to read an electronic message. During processing the READ macro instruction, a transaction start (TRAN-START) macro instruction is issued. Subsequently, the application program A enters the wait state to wait a processing request from the terminal A (200a). PA1 (2) When a processing request on the electronic message is supplied from the terminal A (200a), the application program A receives it. This releases (posts) the application program A from the wait state. PA1 (3) The application program A reads the DB-1 (201a) out of the first external storage (202) to the main memory (204). PA1 (4) The application program A changes on the main memory the contents of the DB-1 (201a) read. PA1 (5) The application program A issues a WRITE macro instruction. During processing of the WRITE macro instruction, a transaction end (TRN-END) macro instruction is issued. PA1 (6) An operation system (OS) requires the HLF writing processing unit (204a) to write the log data into the HLF (206) in the second external storage (205). (1)'-(6)' The same processing as those carried out on the processing request from the terminal A is repeated on the processing request from the terminal B. The processing in (1)-(6) are carried out in parallel to the processing in (1)'-(6)'. PA1 (7) The HLF writing processing unit (204a) writes the log data into the historical log file (206) in response to the instruction supplied from the operation system (OS). PA1 (8) The operation system (OS) notifies the application program A of completion of the log data writing processing into the historical log file (206). PA1 (9) The database DB-1 (201a) changed on the main memory (204) is written into the first external storage (202). PA1 (10) The application program A notifies the terminal A of completion of the update processing to the DB. (7)'-(10)' The same processing as those carried out on the processing request from the terminal A is repeated on the processing request from the terminal B. PA1 (1) When the application program C is initiated, the application program C issues a READ macro instruction. During processing of the READ macro instruction, a transaction start (TRAN-START) macro instruction is issued. PA1 (2) The application program C issues a GET macro instruction to get the database DB-1 (201a). Issue of this GET macro instruction permits the application program C to access to the database DB-1 (201a) exclusively. PA1 (3) To use and update the data contained in the database DB-1 (201a) acquired, the application program C reads a page where the necessary data are stored to a DB updating buffer (208) on the main memory (204). PA1 (4) The application program C issues a MODIFY macro instruction to modify the data content (referred herein to as "A") obtained from the database DB-1 (201a) read in the main memory (208). PA1 (5) The data content is modified from A to A' on the DB updating buffer (208). PA1 (6) A command used for updating in (5) is picked up from the DB updating buffer (208) and is transferred to the HLF buffer (209) as a log data. (2)'-(6)' The same operation as those carried out to the DB-1 is repeated to the DB-2. PA1 (7) The application program C issues a write (WRITE) macro instruction. During processing of the WRITE macro instruction, a transaction end (TRN-END) macro instruction is issued. PA1 (8) The contents of the HLF buffer (209) is written in the historical log file (206). PA1 (9) The data A' on the DB updating buffer (208) is written in the DB-1 (201a). PA1 (9)' A data B' on the DB updating buffer (208) is written in the DB-2 (201b).
Next, processing to acquire the log data is described.
FIG. 11 is a block diagram for use in describing processing to acquire the log data. In this event, the first external storage (202) is provided for the database (DB-1 (201a) and DB-2 (201B)) while the second external storage (205) is provided for the historical log file (206). Provided on the main memory (204) are a buffer (208) for updating the database and a HLF buffer (209) for temporary storing the historical log before writing into the historical log file (206). In FIG. 11, it is assumed that an application program C is loaded on the main memory (204) to access to the databases DB-1 (201a) and DB-2 (201b) successively. Described is processing to acquire the log data in a case of FIG. 11.
As mentioned above, in the conventional database system, a plurality of log data obtained as a result of updating of a plurality of databases are successively stored in a single historical log file (206). In the conventional database system, statistical information for system tuning or accounting information for a user (hereinafter, referred to as a user data) are acquired for every one transaction, which are stored in the historical log file (206) together with the log data. The system tuning used herein means tuning of an I/O load of the database. The accounting information indicates a database fee.
When the system goes down, the command stored in the latest log file before the failure is executed. This allows recovery of the system from a failure to its status at the time when the failure stopped the operation. The term "failure" used herein includes a down to a system and crash of the database itself.
Following are, however, problems in the above mentioned conventional technique.
First, transaction processing cycles per a unit time is increased as the scale of the working is increased. Instead of this, the conventional database system transfers the log data for a plurality of databases to a single HLF buffer (209), following which these data are written together in a single historical log file (206). Accordingly, the processing performance on the transactions cannot be improved due to an I/O neck of the historical log file (206). The I/O neck is a problem occurred with the difference between the processing speed of the application program loaded on the main memory (204) and an access speed to the external storage (205), as the secondary storage. More specifically, the access time to the external storage (205) is significantly slower than the processing speed of the program on the main memory (204). This means that the increased number of the databases (201) require a longer time for writing the log data into the historical log file (206) in the external storage (205). In such a case, the processing speed of the whole system is restricted depending on the performance of the external storage (206).
Second, to recover the database (201), it is necessary to read the historical log file (206) and input the command(s) contained in the historical log file (206) into the processing device where the recovery process is executed. However, the conventional database system stores the log data for the individual databases (201) in the single historical log file (206) in the order of their occurrence. Accordingly, it is necessary upon recovery to retrieve the historical log file (206) and extract only the log data associated with the database to be recovered from crashes. As a result, the recovery and operation of the database becomes complex as the number of the databases is increased. Likewise, the number of the log data is increased as the number of the databases is increased. The increased number of log data results in a long period of processing for retrieving the log data relating to the database to be recovered from the historical log file (206). It is thus disadvantageous in that the necessary time for recovery is elongated.
Third, the conventional database system has a function of acquiring statistical information for system tuning or accounting information for a user for every one transaction to store them in the historical log file (206). However, the conventional database system stores the user data into the historical log file (206) together with the log data. It is thus necessary to extract the user data from the whole historical log file (206) for using the user data. In addition, the above mentioned storing method makes it necessary to retrieve only the log data from the historical log file (206) in which the user data are contained together with the user data. Accordingly, extremely long time is required to recover the database.